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Abstract 


D-STAR™ is a digital streaming over-the-air protocol developed by the Japan Amateur Radio League, 
Inc. (JARL) which supports Ethernet at 128 kbps (DD) and digital voice at 4800 bps (DV). DV uses 
3600 bps for voice (2400 AMBE encoding, 1200 bps FEC) and 1200 bps for synchronization and 
multiuse (approximately 900 bps is available for general use). DD provides an encapsulated Ethernet 
bridge for connecting two or more Ethernet clients over RF. We will explore this bit streaming protocol, 
its primary components, and current implementations. This paper explores the protocol from a 
technical, not subjective, viewpoint. 


Keywords 


D-STAR, D-PRS, Icom 


Introduction 


Icom Incorporated Corporation has introduced a number of radios with D-STAR® capability. D-STAR 
is comprised of the digital voice (DV) protocol (4800 bps) and the digital data (DD) protocol (128 kbps). 
D-STAR® was developed by the Japan Amateur Radio League, Inc. to support digital bit streaming 
modes of communication in the VHF, UHF, and higher Amateur bands. D-STAR” is an open protocol. 
The voice codec (vocoder) used for digital voice (DV) is the proprietary AMBE algorithm developed by 
the same company that owns the P25 voice algorithm. (japan Amateur Radio League, Inc., 2005) 


The DV and DD protocols are highly misunderstood primarily due to our preconceptions of a digital 
protocol and the lack of well translated documents. Also misunderstood is the RF framing information 
carried in both protocols. We will try to push through these misconceptions to expose a very powerful 
and forward-thinking protocol specification. We will also delineate the differences between the basic D- 
STAR specification and the Icom enhancements. 


D-STAR uses the GMSK transmission medium and has no compatibility with existing amateur radio 
digital transmissions. For instance, D-STAR (bit streaming) is not directly compatible with AX.25 
(packet) networks. As with any digital protocols, networks designed around one protocol are not 
directly compatible with another independently developed protocol. 


This paper will first address the content portion of each protocol so the characteristics of the “data” is 
well understood before we address the D-STAR wrapper which is used for routing, identification, and 
other protocol-specific information. Finally, this paper addresses enhancements that Icom has built into 
their radios so it is understood what is part of the D-STAR specification and what are Icom 
enhancements. 
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Digital Voice (DV) 


The Digital Voice (DV) specification is well-defined in the translated D-STAR specification. The 
content bit stream is defined as 72 bits of voice information followed by 24 bits of loosely defined 
“data”. This pattern of 96 bits is repeated for the entirety of the transmission. 
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Figure 1: Digital Voice Components 


The RF header will be addressed later in this paper. The “voice frame” consists of encoded voice and 
forward error correction (FEC) defined as part of the AMBE algorithm. The AMBE encoding is definec 
as being the only content in the voice frames ensuring compatibility with all radios that use the D-STAR 
protocol. 


The “data frame” is defined as (edited from shogen.pdf): 


(3) The first data frame and then every 21st data frame in a repeating cycle, are used only for 
synchronizing data for each modulation type. Synchronization corrects for the lag between transmission 
and reception, including the transit time of communications. 


(4) The data in a data frame is transmitted without modification from the input data. If the data is 
required as error correction or synchronization, these frames are processed before processing the data 
input. 


(5) If the data signal length is greater than the length of the voice communication the transmitting switch 
is turned on until the completion of the data signal manually. The processing can be allowed 
automatically. 


(6) The last data frame, which requires a means of terminating the transmition, is a unique synchronizing 
signal (32 bit + 15bit “000100110101111” + “0”, making 48 bits) as defined by the modulation type. 


Note that the “data frame” is not a data protocol as we normally think of one. There is no specification 
of data information separate from the total transmission. There is no error detection or correction. The 
first frame and every 21“ frame thereafter is reserved for synchronization. The last frame is reserved as 
a terminator indicator. The voice frame is always present and may not be used for anything other than 
the AMBE encoding. 


Also note that these “frames” are not separated by anything. They are not packets. They are definitions 
of bit positions in the continuous DV bit stream. This precludes interleaving of transmissions by 
different stations. Any interleaving of bits by a repeater would be modifying the data from one station 
without any ability to properly identify the data as being from a different source. Any attempt to imbed 
the “change of source” information in the data stream defeats the D-STAR routing information. 
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The JARL intentionally did not define the inter-sync data frame format. This leaves it open to 
manufacturers and radio designers to manipulate as they see fit. These bits make up 1/4" of the total 
4800 bps data stream which gives a maximum transport rate of 1142 bps (1200 * 20/21). 


Icom has made use of these data frames to repeat the RF header, repeatedly send a radio-to-radio 20 
character message, and for carrying rudimentary data supplied by the user. These applications are 
described further in the “Icom Enhancements” section of this paper. It is mentioned here so designers 
are aware that there is a de facto standard use of these data frames already in place as implemented by 
Icom which must be taken into account with any new radio design for compatibility reasons. It is also 
important to note that the serial port on the Icom radios does not give full access to the bits in the data 
frame. This last point brings the maximum transport rate of serial data presented to the serial port of an 
Icom radio down to about 761 bps (1142 * 2/3). If the radios have a “message” programmed in, this 
number is even lower. 


These are primary factors for anyone designing software or hardware for D-STAR DV: 


1. Voice information is always *%4 of the transmission bandwidth. 
2. Even “silent” voice information can be heard due to bit errors and other control issues. 
3. DV transmissions are bit streams, not packets. 
a. DV transmissions are not AX.25 compatible. 
b. DV transmissions are not interleaved. 
c. Only the bit stream is identified, not individual frames. 
4. Data frames contain no forward error correction or error detection information. 
5. Voice information can be accurately reconstructed because of FEC when the data frames are 
rendered virtually useless due to bit errors. 
6. Efficiency dictates short, repetitive data containing error detection information (FCS, CRC, etc.) 
for accurate and reliable data reception. 


Digital Data (DD) 


The Digital Data (DD) specification is well-defined in the translated D-STAR specification. The 
content portion of the bit stream is defined as a complete Ethernet packet, including FCS up to 1500 
bytes long (MTU=1500). It is important to note that the content must be an Ethernet packet (not random 
data). The MTU of 1500 is industry standard. However, transport over the D-STAR IP network 
(discussed later in this paper) may cause multiple tunnel packets to be created for one MTU-size 
Ethernet packet. 
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Figure 2: Digital Data Components 
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DD transmissions are essentially Ethernet bridge transmissions. There are no predefined restrictions on 
the Ethernet packet content in the D-STAR specification. While IP packets have some support in 
current hardware and software implementations (see “Icom Enhancement” section), any valid Ethernet 
packets may be exchanged between stations and still be compliant with the D-STAR specification. 


Each DD transmission encompasses one and only one Ethernet packet. Any error detection and 
retransmission is done by the Ethernet clients. The D-STAR DD protocol provides no forward error 
correction safety for the Ethernet packets. 


The DD protocol provides a simple Ethernet bridge over amateur radio. Because of this flexibility, it is 
important operationally to limit as much as possible the over-the-air communications. Broadcast 
protocols such as NETBIOS must be disabled if successful communications are to occur. 


D-STAR Control 


Every D-STAR transmission starts with synchronization bits followed by an RF header. The RF header 
is critical to proper interpretation of the bit stream. To ensure reliable reception of the RF header, the D- 
STAR specification interleaves forward error correction information and includes a 16 bit CRC for just 
the header information (Figure 1 & Figure 2). The full text description of the flag bytes can be found in 
the D-STAR specification (Japan Amateur Radio League, Inc., 2005). The only portion of the flag bytes of 
interest here is the bit in Flag 1 that the content is either voice or data. The rest of the flag information is 
used to determine repeatability, urgent status, special use, etc. that are not significant to the user but are 
significant to the radio designer and the designer of gateway and repeater software. Designers are 
encouraged to closely review these flag bytes in actual use. 


The rest of the header is dedicated to “ID”. This is the heart of the D-STAR protocol. The D-STAR 
specification defines a callsign as a 7 character sequence of upper-case ASCII characters, numbers, or 
spaces. All callsigns are padded with spaces to fill the 7 characters. Repeater callsigns are restricted to 
6 characters or numbers with a trailing space to accommodate zone communications described later in 
this section. The callsign fields are always 8 bytes long (not variable). The eighth byte is the ID 
character. This character can be an upper-case ASCII character, a number, or a space. 


“Own Callsign” is the originating station’s callsign and ID. This must never be modified at any point 
during the repeating of the signal. “Own Callsign Ext” (Extension, 2) is a 4 character extension that 
facilitates reciprocal licensing prefix identification requirements or can be used by the originating statior 
for any other purpose. It is not used by the D-STAR protocol but must not be altered as it is defined as 
part of the originating station identification. “Own Callsign” corresponds to “MY” in the Icom radios. 


“Companion Callsign” is the callsign and ID of the station being called. D-STAR defines “CQCQCQ ” 
as the generic “broadcast” callsign and ID. This may be a specific station callsign and ID. This may be 
a “zone” or “area” callsign and ID. “Zone” and “area” callsigns and IDs are repeater callsigns and IDs 
prefixed with a forward slash ‘/’. For instance, to make a call to anyone listening to the KSTIT 440 
MHz DV repeater (KSTIT B), an operator would program “UR” to “/KSTIT B” on an Icom radio. Note 
that the repeater callsign has two trailing spaces before the ID but only one trailing space when used as a 
“zone” callsign. This is why a repeater callsign may only be a maximum of 6 characters while a user’s 
callsign may be up to 7 characters. 


“Departure Repeater Callsign” is the repeater callsign local to the originating station “Own Callsign”. 
This corresponds to “RPT1” in the Icom radios. This will be spaces if simplex operation is desired. 
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“Destination Repeater Callsign” is the target repeater callsign LOCAL to the originating station. This 
corresponds to “RPT2” in the Icom radios. This will be spaces for simplex or local repeater operation. 
This can be set to a local repeater callsign and ID for cross-band operation (MY=”AES5PL I’, 
UR="CQCQCQ ”, RPT1="KSTIT A”, RPT2="KSTIT B”). This will be set to the local gateway 
callsign and ID (always ‘G’) to communicate throughout the D-STAR network (even locally) 
(MY="AESPL I”, UR=/KSTIT B”, RPT1="KSTIT A”, RPT2=”"KSTIT G’). 


The callsigns are used for all routing determination by D-STAR repeaters and gateways. D-STAR 
routing is designed on the premise that the operator knows who or where they want to talk to but have 
no need to know how their voice (or data) gets there (network-defined routing). It is also important to 
note that the routing is of the origin station’s transmissions and does not affect the “companion” 
station’s routing. For the “companion” to properly respond via D-STAR routing (non-local) so the 
origin station hears them, the “companion” station must either program UR with the origin station’s 
callsign and ID or the zone callsign of the repeater that the origin station is using. As you will see, the 
preferred method is using the origin station’s callsign and ID because that is all that is seen at the remote 
end of the transmission. 


This methodology sets up the amateur radio equivalent of “Follow Me Roaming” in the early days of 
cellular telephone networks. Every time a station transmits via a D-STAR repeater, that station’s 
information is made available to the D-STAR network. This makes it possible for me to program my 
radio’s UR with my wife’s callsign and have my station callsign and ID programmed in her radio’s UR, 
and we can communicate with each other anywhere in the world. 


Key factors regarding the RF header information: 


1. Flags indicate type of D-STAR transmission and miscellaneous control information. 
“Own Callsign” 1 & 2 (extension) must never be modified 

3. “Companion Callsign” is the station intended to hear the transmission. 

a. Per the precepts of amateur radio, there are no private communications (everyone with a 
D-STAR radio in range of the transmitting station(s) can hear the conversation). 

b. “Companion Callsign” is used by D-STAR gateways (routers) to determine the repeater 
to transmit on. 

c. “Companion Callsign” is used solely for D-STAR routing. Other uses such as listening 
only for a specific station are possible but not covered in the D-STAR specification. 

4. “Departure Repeater Callsign” is the repeater local to the transmitting station. This can be 
modified by D-STAR gateways at the “Companion” end to be the repeater local to the 
“Companion”. 

5. “Destination Repeater Callsign” is the “second” “repeater” the transmission is to pass to/through. 
This will normally be the local gateway or another local repeater module. This can be modified 
by D-STAR gateways at the “Companion” end to be the gateway local to the “Companion”. 

6. No other routing information is contained in the D-STAR protocol. None may be added as any 
additions would break the existing networks. 

7. No modification of the RF header is allowed on RF (repeaters, etc. must leave the header intact). 


D-STAR Network 


The D-STAR specification defines the repeater controller/gateway communications and defines the 
general D-STAR network architecture. The following diagram is taken from the English translation of 
the D-STAR specification: 
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The Comp. IP and Own IP are shown for reference if this was a DD communications. As they do not 
change and are not passed as part of the D-STAR protocol, they can safely be ignored for the purposes 
of the following explanation. 


Headers | through 4 are W$1QQQ calling W$1WWW. Headers 5 through 8 are W$1WWW calling 
W$1QQQ. Note that “Own Callsign” and “Companion Callsign” are never altered in either sequence. 
The “Destination Repeater Callsign” and the “Departure Repeater Callsign” are changed between the 
gateways. This is so the receiving gateway and repeater controller know which repeater to send the bit 
stream to. It also makes it easy to create a “One Touch” response as Icom has done by simply placing 
the received “Own Callsign” in the transmitted “Companion Callsign’, the received “Destination 
Repeater Callsign” in the transmitted “Departure Repeater Callsign”, and the received “Departure 
Repeater Callsign” in the transmitted “Destination Repeater Callsign”. 


Use of the “special” character ‘/’ at the beginning of a callsign indicates that the transmission is to be 
routed to the repeater specified immediately following the slash. For instance, entering “/K5TIT B” in 
the “Companion Callsign” would cause the transmission to be routed to the “K5TIT B” repeater for 
broadcast. Using the above example, W$1QQQ would put “/W$1SSS ” in the “Companion Callsign” 
for the same sequence | through 4 to occur. At the W$1VVV gateway, however, the “/W$1SSS ” in the 
“Companion Callsign” would be changed to “CQCQCQ ”. All stations within range of W$1SSS would 
see the transmission as originating from W$1QQQ and going to CQCQCQ just like that station was 
local (but the “Departure Repeater Callsign” would be “W$1VVV G” and the “Destination Repeater 
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Callsign” would be “W$1SSS ”). Replying would still be done the same way as before since the 
received “Companion Callsign” is ignored when programming the radio to reply. 


Every “terminal” (station) has an IP address assigned to it for DD purposes. The address is assigned 
from the 10.0.0.0/8 address range. The D-STAR gateway is always 10.0.0.2. The router to the Internet 
is always 10.0.0.1. The addresses 10.0.0.3-31 are reserved for local-to-the-gateway (not routable) use. 
What this makes possible is the ability to send Ethernet packets to another station by only knowing that 
terminal’s IP address and the remote station can directly respond based solely on IP address. This is 
because the gateway software can correlate IP address with callsign and ID. This makes it possible to 
route DD Ethernet packets based on the “Companion Callsign” or based on IP address with “Companion 
Callsign” set to “CQCQCQ ”. 


Key points of D-STAR routing: 


1. Simplex uses only “Own Callsign” and “Companion Callsign”. The repeater callsigns are set to 
spaces. “CQCQCQ ” is the universal “calling everyone” callsign and ID for the “Companion 
Callsign” only. 

2. Local repeater use sets only the “Departure Repeater Callsign” repeater. “Destination Repeater 
Callsign” is set to spaces. 

3. Accessing the gateway requires the local repeater in “Departure Repeater Callsign” and the local 
gateway in “Destination Repeater Callsign”. 

4. Routing outside of the local zone requires programming the radio to access the gateway. 

5. Inter-zone and inter-area routing by station callsign and ID requires the radio to be programmed 
to access the gateway. 

6. Inter-zone and inter-area routing using the slash with a repeater callsign and ID requires the radic 
to be programmed to access the gateway. 

7. DD routing based on assigned 10.0.0.0/8 IP address requires the radio to be programmed to 
access the gateway. 

8. Routing is unidirectional. Responding station(s) must program their radios correctly to reach the 
calling station. 

a. D-STAR routing is not linking, it is routing of the bit stream from source to destination. 
b. Responding requires proper configuration of the responding radio. 


Icom Enhancements 


The D-STAR specification defines the protocols and general network architecture. It is left to the 
manufacturers (including independent developers) to refine this into an operational model. As Icom is 
the first manufacturer of D-STAR radios and software, they have had a significant amount of flexibility 
in their implementation. 


On the RF side, the data frame content in the DV protocol is generally undefined (every 21" frame and 
the last frame are reserved). This is the only opportunity for customization of the RF signal in the 
specification that does not have to be forced compatible with other radios and software. Icom has made 
use of it for 3 different and distinct functions which are “hidden” from each other by a “control” byte 
occupying the first byte of the 3 byte data frame: 


1. Control functions including repeating the RF header periodically to help receiving radios get a 
valid RF header for informational purposes only when operating under noisy conditions. 
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2. Repetitive transmission of a 20 character message for display on the receiving radio(s)’ front 
panel. The message is displayed upon reception in a scrolling manner. 
3. Passing 8 bit data between data ports on the radios. 


#1 is solely used by the radios to recover sending callsign information on a noisy connection. Because it 
is not defined in the specification, it cannot be used to alter a header that has already been passed. It is 
very unlikely that these will be received more intact than the original RF header because the data frames 
do not have forward error correction. 


#2 exists to allow a person to put a short announcement message in their transmission. This is not 
modifiable while transmitting and very difficult to change in-between transmissions. 


#3 is usable by any application connected to the serial port on an Icom radio. As indicated, the data on 
the serial port is not placed into the data frames unaltered. It is transmitted 1 or 2 bytes at a time with 
the Icom “control” byte occupying the first byte of the data frame. Icom also implemented always- 
enabled xon/xoff flow control. This precludes the use of those characters in the data stream. Because of 
bit errors that can be received, it also precludes use of xon/xoff flow control by the attached device as 
there is no way to know if an xoff is received or issued by the radio. Some radios use the serial port to 
control the radio by using certain bytes (mostly 0xF0-OxFF) to denote control information. This means 
that these characters are also off-limits. 


Icom makes use of #3 to pass GPS information. Because this information is passed using the #3-type 
control bytes, it is visible to the serial port on radios not running in GPS mode (GPS modes block the 
serial port from the data frames). The original GPS format (implemented on all radios that support GPS) 
is standard NMEA GPS strings with checksums followed by an ASCII line that contains the transmitting 
callsign, ID, and a duplicate of the 20 character message being sent to the front panel. This line is 
generated by the transmitting radio and is not interpreted by the receiving radio. GPS-A mode was 
introduced to provide a more concise and reliable position representation. GPS-A mode consists of a 
single APRS format line prefixed by a CRC. 


It is important to remember that all uses of the data frames are not protected from bit errors nor do they 
have any indication of bit errors. In the case of #1, the RF header contains a CRC for validation. #2 has 
no validation. Validation with #3 is left to the connected applications. 


The other area open for significant customization is the gateway operation and the gateway-to-gateway 
communications. The latter may be addressed in a future addition to the D-STAR specification. 
However, it was never the intention of the JARL to dictate how software or devices operate so gateway 
operation will be left to the manufacturers and independent developers. 


The Icom gateway software is currently at version 2 released this year. Version 1 was based on a mesh 
network design where all gateways communicate directly with all other gateways. Specifically, when 
one gateway’s table(s) gets updated, that gateway contacts all other gateways with the new information. 
While this works well with small gateway networks, it became obvious that it would not be supportable 
with the explosive growth experienced in the world-wide D-STAR network. To meet the growth 
requirements of the new D-STAR network, Icom introduced G2 (Gateway Version 2) earlier this year. 


G2 is designed around a hub and spoke topology for information exchange but maintaining the basic D- 
STAR communications architecture where DV and DD communications occur directly between the 
gateways. Gateways exchange information with the central Trust Server regarding their callsign (zone 
call), Internet IP address, connected area repeaters, and recent activity on the area repeaters. This 
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information is mentioned in generalities in the D-STAR specification but the actual data interchange 
format is not defined. To accomplish the allocation of 10.0.0.0/8 addresses for individual stations, the 
G2 software automatically reserves 8 addresses for each callsign registered through the gateway 
registration software. Each registered user can designate which ID is assigned to the specific IP address 
and also a DNS name in the dstar.local domain. This information is also exchanged with the central 
Trust Server. The IP address groups are obtained from the Trust Server so there is no duplication in the 
network. The central Trust Server then broadcasts the information received from individual gateways to 
all of the gateways so they can quickly determine which gateway a user or repeater is connected to and 
the Internet IP address of that gateway. 


One final note on the G2 gateway: due to a programming restriction in station registration form, G2 
restricts the ID character (8" character of callsign) to a space or upper-case alphabetic (no numbers). 
This restriction is specific to the G2 software, not to the D-STAR specification. 


Independent Enhancements 


In addition to Icom, there have been other developers create applications for the D-STAR systems. 
Icom’s adherence to the D-STAR specification has lead to DStarMonitor which monitors the 
repeater/gateway communications and parses the information into database entries and parses the Icom 
“serial port” data to a TCP port for use by an application just like the application would work connected 
to a radio monitoring the repeater frequency. 


DPlus is a multifaceted application that runs on the gateway PC. It also monitors the repeater/gateway 
communications and provides enhanced features like echo, prerecorded announcements, DV reflectors, 
etc. 


D-PRS is a translation specification for the Icom GPS information to APRS format and to use the Icom 
serial data port for reliable transport of APRS packets between APRS clients. 


Other applications tend to concentrate on the Icom serial port. These include messaging, form 
completion, and small file transfer. 


There are independent gateway projects underway at the time of writing of this paper. Further 
information may be available for presentation at DCC 2008. 


Conclusion 


The D-STAR specification is a focused definition of 2 RF digital protocols: digital voice and digital 
data. It also defines the control information contained in every transmission and the network 
architecture that control information supports. Finally, it defines the repeater/gateway communications 
protocol to ensure compatibility across platforms between gateways and repeaters. 


Digital voice (DV) is a protocol designed to convey audio information. Because of its design, there is 
limited bandwidth for very low speed data to accompany the audio information. Icom has made 
available a serial port to utilize a subset of that low speed data bandwidth by applications attached to the 
radios. Icom uses this same subset of low speed data bandwidth to convey GPS information to remote 
radios. 
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Digital data (DD) is a protocol designed to convey Ethernet packets. Implied D-STAR network design 
designates the 10.0.0.0/8 IP address range for use to connect network devices via the DD protocol. The 
DD protocol is not limited to IP packets although extra features are available to IP packets. 


The D-STAR specification defines the repeater/gateway IP communications to facilitate multiple 
repeater or gateway platforms. This portion of the specification reinforces the overall network 
architecture mentioned elsewhere in the specification. The specification purposely does not define how 
any function such as the gateway operates. Only the communication between entities is defined in the 
specification. The gateway/gateway communication is yet to be included at the time of the writing of 
this paper. 


The D-STAR network architecture is purely based on callsign and station ID. The callsign and ID 
applies to individual stations, repeaters, and gateways. All routing is handled within the gateways. The 
user only needs to know who they want to talk to and what the callsign and ID is of the local repeater. 


D-STAR brings true world-wide station-to-station communication capabilities to amateur radio. 
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